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A method for controlling access to a man- 
agement information base (MIB), via a communi- 
cation framework (FW) between applications (A, B, 
C, D, ...)» by a given application or application user 
transmitting a request to one or more specified ob- 
jects in a distributed management environment The 
method comprises checking the access rights of the 
application or application user connected directly 
(A, B, O or indirectly (D) to the communication 
framework, said rights being denned in an element 
of a capacity list stored in a database. A capacity 
consists of a class or set of classes of objects con- 
taining the specified object(s) and a set of authorised 
and ordered operations. The operation corresponds 
to the transmitted request and, when authorised, is 
carried out on instances of the specified object(s) in 
the object class. The processed objects are hetero- 
geneous. 



(57) Abreg* 

La presents invention conceme un proce*de* de contrdle d'acces a la base d'informations de gestion appelee MIB via P infrastructure 
de communications (FW) liant des applications (A, B, C, D, .„), d'une application ou d'un utilisateur d'une application donnee emettant une 
requite vers un ou plusieurs objets specifies dans un environnement de gestion distribute. Le present procexl6 est remarquable en ce que 
1'application ou I'utilisateur de 1'application. connectee directement (A, B, C) ou indirectement (D) a l f infrastructure de communications, 
se voit contrdler ses droits d'acces ddMnis dans un element d'une liste de capacity's stockee dans une base de donnees, une capacit* elant 
constitute d'une classe ou d'un ensemble de classes d'objets contenant le ou les objets specified et d'un ensemble d'operations autorisees et 
ordonnees, I'opecauon correspondant a la requ&te emise et, si elle est autorisee. 6tant a effectuer sur des instances du ou des objets specifies 
de ladite classe d'objets, les objets traites extant de nature h6te*rogcne. __ 
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Procedt de controle d'acces a la base d'informations de gestion via 
I'infrastructure de communications d'une application ou d'un utilisateur 

d'une application. 

5 La presente invention concerne un precede de controle d'acces a la base 
d'informations de gestion via I'infrastructure de communications liant des 
applications, d'une application ou d'un utilisateur d'une application donnee 
emettant une requete vers un ou plusieurs objets specifies dans un 
environnement de gestion distribute. 

10 

De maniere generate, un environnement de gestion distribute permet d'integrer 
la gestion des systemes, des reseaux et des applications utilisateur. Les 
applications de gestion sont concues de maniere a avantageusement dissimuler 
a I'utilisateur les etapes detaillees necessaires pour effectuer des travaux de 

15 gestion et garantir I'integrite des informations de gestion. Ces applications 
gerent des objets en utilisant des interfaces claires et concises avec les services 
communs de gestion. Les services communs de gestion permettent de simplifier 
le developpement des applications de gestion. Des services "bases 
d'informations de gestion", appeles couramment par I'homme du metier MIB 

20 (Management Information Base), permettent aux applications de gestion de 
manipuler lesdites informations de gestion, ces services utilisent, de preference, 
les normes applicables comme les normes OSI CMIS/CMIP (Open Systems 
Interconnection Common Management Information Services/Common 
Management Information Protocol) et Internet SNMP (Simple Network 

25 Management Protocol). Un objet gere est, dans cet environnement informatique, 
une representation de ressources telles qu'une machine, un fichier, un 
peripherique, un utilisateur, une application, etc.. Une MIB qui est en fait un 
ensemble d'objets represente les differentes ressources a administrer dans un 
systeme. Un objet d'une MIB est defini par une clas'se d'objets (correspondant a 

30 un type d'objet) et une instance de cette classe d'objets. Une requete est emise 
par une application en vue de consulter et/ou de modifier un objet de la MIB, elle 
est caracterisee par le type d'operation a appliquer sur un ou plusieurs des 
objets de la MIB. Les services de securite de I'informatique distribute sont 
composes de fonctions qui completent celles fournies par les plates-formes ou 

35 applications individuelles. Les services de securite des systemes Sexploitation 
doivent respecter des normes etablies qui comprennent, entre autres, le controle 
d'acces qui permet de n'accorder un acces determine qu'a des utilisateurs 
autorises. En fait, I'administrateur d'une ressource accorde des droits d'acces a 
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cette ressource a des utilisateurs specifies. Un tel mecanisme permet de 
contrdler quelle type d'action peut etre executee et sur quelle ressource. Dans 
ces conditions, les services de securite controlent tous les acces a I'ensemble du 
systeme d'information afin de preserver son integrite et sa confidentiality dans le 
5 reseau au niveau requis. 

De maniere plus particuliere, I'exploitation efficace d'un tel environnement de 
gestion distribute implique une architecture flexible qui autorise une 
administration aisee de differentes sortes d'objets. Au centre de cette 

10 architecture se trouve ('infrastructure de communications (appelee egalement 
''framework" par I'homme du metier) dont I'objet est de gerer et d'aiguiller toute 
communication a Tinterieur dudit environnement de gestion distribute. Dans cet 
environnement done, tout composant ou application qui communique avec un 
autre composant ou une autre application le fait par I'intermediaire et en utilisant 

15 T infrastructure de communications dont le role principal est d'aiguiller ou de 
"router" les requetes en provenance duplications vers les gestionnaires 
d'objets adequats. 

Jusqu'a present, dans les differents precedes exploites, ce type d'operations de 
20 mise en communication etait effectue sans que ('infrastructure de 
communications n'exerce le moindre controle, e'est-a-dire qu'une quelconque 
application pouvait emettre une quelconque requete a destination d'un 
quelconque objet. Force est de constater que cette situation est extremement 
prejudiciable et a pour principal inconvenient de ne pouvoir garantir Tintegritt et 
25 la confidentiality des informations relatives aux objets ainsi accedes. 

La presente invention a pour but de remedier a cet inconvenient retrouve dans 
les differents precedes de I'art anterieur et propose un precede dans lequel un 
controle d' acces est exerce via r infrastructure de communications non seulement 
30 concemant les applications, les utilisateurs et les objets a acceder mais aussi 
concernant les differentes operations a effectuer sur lesdits objets et ceci, de 
maniere aisee et efficace. 

Pour cela, le precede de controle d' acces a la base d'informations de gestion via 
35 Infrastructure de communications mentionne dans le preambule est 
remarquable en ce que ('application ou I'utilisateur de ('application, connectee 
directement ou indtrectement a ('infrastructure de communications, se voit 
controler ses droits d'acces definis dans un element d'une liste dite de capacites 
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stockee dans une base de donnees, une capacite etant constitute d'une classe 
ou d'un ensemble de classes d'objets contenant le ou les objets specifies et d'un 
ensemble d'operations autorisees et ordonnees, Toperation correspondant a la 
requete emise et, si elle est autorisee, etant a effectuer sur des instances du ou 
5 des objets specifies de ladite classe d'objets, les objets traites etant de nature 
heterogene. 

Ainsi, selon Tidee de Tinvention et ceci centre toute attente, a partir de 
Infrastructure de communications tout acces a un quelconque objet peut §tre 

10 controle, puisqu'un controle d'acces a la base d'informations de gestion via 
Tinfrastructure de communications d'un utilisateur d'une application, directement 
ou indirectement connectee a ladite infrastructure de communications, est 
effectue au niveau exact d'un objet ou d'un ensemble d'objets precisement 
determines et appartenant a une quelconque classe repertoriee dans la base de 

15 donnees, mais egalement au niveau de chaque operation desiree realisee, selon 
la requete emise, sur des instances d'un ou plusieurs desdits objets determines. 
Ceci est autorise du fait que sont utilisees toutes les caracteristiques de finesse 
et de precision presentees par un protocole administratis par exemple le 
protocole CMIP avec ses fonctions particulieres. Avec ce precede et avec le 

20 protocole CMIS/CMIP qui permet d'aider efficacement a I'unification d'un 
ensemble d'objets a traiter, un quelconque ensemble d'objets heterogenes peut 
etre avantageusement et aisement administre alors qu'auparavant, avec les 
precedes de Tart anterieur. chaque protocole necessitait une application 
particuliere. 

25 

Avantageusement, le proc6d6 de controle d'acces a la base d'informations de 
gestion via Tinfrastructure de communications est remarquable en ce que 
Tapplication ou I'utilisateur d'une application directement connectee a 
Tinfrastructure de communications est identifie soit au moyen de son adresse et 
30 de son identifiant, soit au moyen de son nom repertorie par un service de 
nommage, autorisant, lorsque I'utilisateur est reconnu, la connection et faeces 
aux droits definis dans la base de donnees. 

Egalement de maniere avantageuse : le precede de controle d'acces a la base 
35 d'informations de gestion via Tinfrastructure de communications est remarquable 
en ce que, dans le cas ou une premiere application est indirectement connectee 
a Tinfrastructure de communications par T intermediate d'une seconde 
application directement connectee a Tinfrastructure de communications sous un 
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nom particulier, les requetes et les reponses aux requetes transitant par la 
seconde application, si la seconde application travaillant alors pour la premiere 
application donne avec remission de la requete I'identite de I'utilisateur de la 
premiere application, I' infrastructure de communications controle la requete 
comme si cette premiere application avait envoye directement ladite requete, 
alors que si la seconde application ne precise pas, dans la requete, I'identite de 
la premiere application, Infrastructure de communications realise le controle en 
utilisant les droits par defaut d'un utilisateur de la seconde application si cet 
utilisateur est defini tandis que si ce dernier n'est pas defini, I'infrastructure de 
communications realise ce controle en utilisant les droits d'un utilisateur 
particulier appele "autre utilisateur" si ce dernier est defini dans la base de 
donnees. 


II apparait done qu'une application ou un utilisateur de I'infrastructure de 
communications peut etre defini de deux manieres differentes. Selon une 
premiere maniere, il peut etre defini par un couple d'informations transmis lors 
de la demande de connexion et constitue par son adresse et son identifiant, par 
exemple le couple (ip, uid) dans lequel ip est I'adresse Internet a laquelle tourne 
I'application et uid est un nombre identifiant I'utilisateur d'un systeme note pour 
lequel toume ^application. Selon une seconde maniere. il peut etre defini 
simplement par un nom lorsque I'application utilisant I'infrastructure de 
communications ne possede pas ce couple, adresse et identifiant, ou s'il n'est 
pas desire I'utiliser. Toutes les definitions des utilisateurs de I'infrastructure de 
communications ainsi que leurs droits relatifs sont stockes dans une base de 
donnees, de maniere a ce que, lorsqu'une application demande a etre connectee 
a i'infrastructure de communications, cette derniere puisse verifier I'existence de 
I'identite de I'utilisateur dans ladite base de donnees pour accepter ou interdire, 
si I'identite n'est pas trouvee, la connexion. En outre, une application peut etre 
identifiee au moyen de son nom repertorie dans un service de nommage, par 
exemple 'TAptitle" defini dans les normes ISO X500. Ainsi, le nom connu du 
service de nommage et designe par "Aptitle" par I'homme de metier est en fait le 
titre de I'application et peut etre constitue d'une chaine de caracteres, d'un 
numero, d'un nom, etc.. Pour preciser, la fonction du service de nommage est 
d'assurer la mise en correspondance d'objets ou de noms orientes utilisateur 
d'un environnement d'informatique distribute et d'entrees orientees informatique 
dans une base de donnees repartie. Les objets a nommer sont des entites 
comme des pays, des organisations, des personnes, des groupes, des fonctions 
dans une organisation, des ordinateurs, des imprimantes et des fichiers, des 
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processus et d'autres services applicatifs. Outre le fait qu'un service de 
nommage permet d'augmenter significativement les performances en accroissant 
efficacite et vitesse, il donne aussi la possibility d'ajouter aisement des domaines 
locaux ou eloignes, c'est-a-dire de s'adapter a des grands reseaux et/ou des 
5 petits reseaux. 

En outre, de maniere remarquable, selon le procede de controle d'acces a la 
base d' informations de gestion via I' infrastructure de communications, chaque 
requete emise est testee relativement aux droits d'acces de I'utilisateur d'une 
10 application ou d'une application, ce test consistent a verifier le type de la requete 
et son niveau dans une suite ordonnee de requetes, la classe d'objets requise 
qui peut etre etre une classe autorisee ou une classe appartenant a I'ensemble 
des classes autorisees defini dans une capacite et I'appartenance de I'instance 
d'objets requise a un ensemble d'instances d'objets autorise appele domaine. 

15 

En effet, il peut etre, a cet endroit, precise qu'il existe deux types d'utilisateurs de 
I'infrastructure de communications, I'utilisateur dit privilegie qui peut acceder 
sans aucune restriction a tous les objets et I'utilisateur dit normal, identifie, 
comme cela a ete vu precedement, soit par le couple adresse et identifiant, soit 
20 par un nom, cet utilisateur dit normal ne pouvant acceder qu'a un ensemble 
predetermine d'objets definis dans la base de donnees. L'existence de 
I'utilisateur dit privilegie est necessaire a la configuration des droits d'acces dans 
I'infrastructure de communications, en particulier, lors de la premiere 
initialisation, cet utilisateur est implicitement declare au sein de I'infrastructure 
25 de communications. L'infrastructure de communications peut ainsi deduire, des 
informations stockees dans cette base de donnees, que I'utilisateur dit normal 
peut acceder a: 

- une liste de classes ou d'ensemble de classes d'objets autorisees, 

t 

i 

- la capacite, sachant que pour chaque classe ou ensemble de classes 
d'objets, il correspond des ensembles d'instances de classes d'objets regroupes 
en domaines auxquels I'utilisateur normal a le droit d'acceder et des operations 
permises sur ces objets, operations par exemple du type CMIS comme 
I'application des fonctions: Get, Get scope, Set, Set scope, Action, Action 
scopee. Create, Delete, Delete scope, le terme "scope" signifiant ici que la 
fonction concernee est appliquee avec une portee ou une profondeur differente 
de celle de I'objet specifique de la base et par consequent a un, plusieurs ou 


30 
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tous les objets contenus dans le sous-arbre de la base d'informations de gestion 
(MIB) a partir de Pobjet de base requis. La capacite est done constitute d'une 
classe d'objets, des domaines qui y sont relatifs et de I'operation (par exemple 
CMIS) permise appliquee avec precision a une selection d'objets. 

Ainsi, les droits d'acces d'un utilisateur normal sont definis au moyen d'une liste 
de capacites comme ci-dessus determinee. De cette maniere et grace a ces 
regies, I' infrastructure de communications peut controler finement toutes les 
requetes emises par un utilisateur normal. 

Un utilisateur de I'infrastructure de communications peut, comme cela a ete dit 
ci-avant, etre identifie par I'intermediaire d'un nom. Ce cas peut correspondre a 
une premiere application qui emet des requetes vers I'infrastructure de 
communications pour le compte d'une seconde application. En effet, si la 
seconde application n'est pas executee pour un utilisateur de I'infrastructure de 
communications (ce dernier n'etant pas identifie par un nom ou un couple, 
adresse et identifiant (ip, uid)), I'infrastructure de communications ne peut 
identifier l'utilisateur de cette seconde application, aussi dans ce cas particulier , 
I'infrastructure de communications devra utiliser des droits d'acces par defaut 
identifies par un nom de la maniere suivante, en sachant que la premiere 
application travaillant pour la seconde doit se connecter a ['infrastructure de 
communications au moyen du dit nom: 

- si ledit nom existe et correspond a un utilisateur de I'infrastructure de 
communications specifie dans la base de donnees, I'infrastructure de 
communications utilise les droits associes a cet utilisateur pour controler les 
requetes emises par cette application. L'utilisateur de I'infrastructure de 
communications qui est identifie par ce nom est appele "utilisateur par defaut" de 
la premiere application. Ce nom permettant a la premiere application de se 
connecter sert de nom pour l'utilisateur par defaut de la premiere application, 

- si ledit nom n'existe pas dans la base de donnees, I'infrastructure de 
communications utilise les droits d'un utilisateur particulier appele "autre 
utilisateur" existant dans la base de donnees. 

De cette maniere, tout utilisateur ou toute application peut etre identifie et 
directement ou indirectement connecte a I'infrastructure de communications pour 
traiter de maniere selective et precise differents objets heterogenes. 
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De plus de maniere particuliere, selon le procede de controle d'acces a la base 
d'irrformations de gestion via I'infrastructure de communications, chaque requete 
emise est testee relativement aux droits d'acces des utilisateurs, ces droits etant 
5 definis de facon non enumerative sur des classes non encore connues et des 
instances non encore decouvertes de telle maniere que: 

- les classes d'objets testees ou un ensemble de classes d'objets testees 
aient un radical commun et notamment la classe* (classe etoile) designant toutes 

10 les classes existantes et a venir, le radical commun etant, par definition; la 
relation de nommage dans I'arbre d'enregistrement des identifieurs (appele 
"registration tree" par Thomme du metier) dont sont extraites les classes, 

- un domaine d'instances d'objets soit defini comme un ensemble 
15 d'instances d'objets existants et a venir appele domaine* (domaine etoile), ■, 

- par la definition d'une requete scopee sur un domaine, un utilisateur 
d'une application ait acces a toutes les instances d'objets appartenant a ce 
domaine mais aussi aux instances d'objets qui sont hierarchiquement inferieures 

20 relativement auxdites instances d'objets appartenant a ce domaine dans la base 
d'informations de gestion. 

Les differentes caracteristiques ci-dessus enoncees et revendiquees seront bien 
comprises en se reportant aux differents exemples donnes dans la suite et en 
25 particulier a I'exemple de capacites d'utilisateurs qui y est fourni. 

La description suivante en regard du dessin annexe, le tout donne a titre 
d'exemple non limitatif, fera bien comprendre comment I'invention peut etre 
realisee. 

30 

Sur la figure unique est represents de maniere tres schematique un exemple 

d'environnement pour le dialogue entre diverses applications A, B, C, D par 

I'intermediaire d'une infrastructure de communications FW effectuant done, pour 
autoriser ce dialogue, un controle et un test uniques avant d'aiguiller les 
35 requetes vers la destination requise et en particulier vers la base d'informations 
de gestion MIB representant les differents objets a administrer. II est ici rappele 
que le role principal de I'infrastructure de communications est de "router" les 
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requetes vers les gestionnaires d'objets (appeles aussi par I'homrne du metier 
agents integrateurs) adequats. 

En mode "controle d'acces", I' infrastructure de communications FW controle 
I'application (A, B, C. D, ..,) lors de la demande de connexion, application qui 
emet des requetes vers I'infrastructure de communications. Une application 
connectee a I'infrastructure de communications est identifiee comme un 
utilisateur ayant des droits d'acces pour une operation donnee a des ensembles 
d'objets determines. Plus precisement, une application connectee a 
I'infrastructure de communications s'identifie a partir de son identifiant, par 
exemple "I'Aptitle" defini dans les normes ISO X500, I'infrastructure de 
communications deduisant les droits d'acces a la base d'informations de gestion. 
Dans ce mode, une requete emise par une application peut done etre rejetee ou 
acceptee selon les droits d'acces definis pour cette application dans une base 
de donnees. II existe, de plus, deux types Sexploitation de ce mode "contrfile 
d'acces", un premier type dit "faible" pour lequel toutes les requetes sont 
controlees par ('infrastructure de communications a I'exception des requetes de 
consultation de type Get et un second type dit "fort" pour lequel toutes les 
requetes, sans distinction, sont contrdlees par I'infrastructure de 
communications. 

Une fois que I'infrastructure de communications est correctement initialisee, elle 
verifie si une application peut lui etre ou non connectee et ceci de la maniere 
suivante: 

- si I'application tourne pour un utilisateur privilegie alors la connexion est 
acceptee, 

- si I'application tourne pour un utilisateur normal qui est repertorie dans la 
base de donnees, la connexion peut etre soit acceptee. soit rejetee en fonction 
des droits definis pour cet utilisateur. 

II est a noter que durant la phase ^initialisation, qui consiste a initialiser la base 
de donnees, aucune connexion ^application ne peut etre acceptee. 

Ensuite, une fois connectee a I'infrastructure de communications, I'application 
peut emettre des requetes vers cette demiere. Les requetes contrdlees par 
I'infrastructure de communications sont du type Get, Set, Action, Create, Delete. 
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Lorsqu'une requete est acceptee, le traitement normal de ('infrastructure de 
communications consiste alors a "router" cette requete. Par contre, dans le cas 
ou cette requete est rejetee, Pinfrastructure de communications renvoie en 
reponse un message "erreur locale" ("local error") vers I'application indiquant la 
5 nature de I'erreur et genere un message "d'echec" ("event violation") qui indique 
que cette requete a ete rejetee par ^Infrastructure de communications afin 
d'archiver les violations de droits d'acces. 

De maniere generalisee, I* infrastructure de communications contrdle une requete 
10 comme suit: 

- si I'application tourne pour un utilisateur privilegie, la requete est 
acceptee en notant cependant qu'un traitement de controle particulier est 
effectue pour une application, telle que C, travaillant pour une autre application, 

15 comme D, ce cas sera explicite ci-apres, • 

- si I'application tourne pour un utilisateur normal, la requete est acceptee 
si il existe une capacite relative audit utilisateur normal qui verifie les conditions 
suivantes: la classe d'objets est la classe d'objets definie dans la capacite, 

20 Pinstance d'objet existe dans un des domaines associes a la capacite et 
Poperation est autorisee dans la capacite, 

- si P infrastructure de communications est en mode "contrdle d'acces" de 
type dit "faible" et que la requete est une requete de consultation de type Get 

25 (exception au controle), cette requete est acceptee. 

L'appellation "application travaillant pour une autre application" signifie qu'une 
application intermediate, application C sur la figure, connectee directement a 
('infrastructure de communications FW, emet des requetes pour le compte d'une 

30 autre application, application D sur la figure, les, resultats et reponses aux 
requetes emises etant ensuite retransmis par I'application C a I'application D. 
Ainsi, I'application C peut controler si I'application D a le droit d'emettre la (ou 
les) requete(s) a destination des objets concernes ou a defaut laisser 
Pinfrastructure de communications controler si ce droit existe ou non. Si 

35 Pinfrastructure de communications realise ce controle: 

- I'application C doit se declarer comme etant une application travaillant 
pour I'application D, en d'autres termes, Pinfrastructure de communications FW 
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doir savoir que I'application C travaille pour d'autres applications et en particulier 
dans le cas de la presente figure pour I'application D, ainsi, I'application C est 
connue de I'infrastructure de communications comme une application speciale 
ayant le droit d'emettre des requetes pour le compte d'une autre application, 

- I'application C doit etre lancee par un utilisateur privilegie et se 
connecter a I'. infrastructure de communications au moyen d'un nom, 

- I'application C peut donner avec remission de la requete et dans la 
requete I'identite (I'identite de I'utilisateur de I'infrastructure de communications) 
de I'application D. Par consequent, I'infrastructure de communications controle la 
requete comme si I'application D lui avait envoye directement ladite requete. 
Lorsque I'application C ne precise pas, dans la requete, I'identite de I'appl.cat.on 
D alors I'infrastructure de communications realise le controle en ut.lisant les 
droits par defaut d'un utilisateur de I'application D si cet utilisateur est def.n. et 
lorsque ce dernier n'est pas defini. I'infrastructure de communications realise ce 
controle en utilisant les droits d'un utilisateur particulier appele "autre util.sateur" 
si ce dernier est defini dans la base de donnees. 

^application C doit done indiquer a I'infrastructure de communications qu'elle 
travaille pour d'autres applications, elle peut le faire de deux man.eres 
differentes: 

- de maniere statique: ajouter I'indicateur YES_CONTROL_ACCESS_ID 
(defini ci-apres) dans le fichier de caracteristiques de gestionnaires d'objets de 
I'application C, appele dans la suite fichier "omc". Le nom de I'utilisateur par 
defaut de I'application est le nom du gestionnaire defini dans le fichier "omc , 

- de maniere dynamique: emettre une requete d'action vers I'infrastructure 
de communications indiquant le nom pour la connexion de I'application C et le 
nom de I'utilisateur par defaut de I'application C. 

Dans le cas d'une declaration statique. le fichier "omc" est utilise pour declarer 
un gestionnaire d'objets. Le parametre ACTL.FLAGS. relatif aux indicateurs de 
controle d'acces, peut etre ajoute et est optionnel. Deux indicateurs sont defin.s 
pour le controle de I'infrastructure de communications, ils sont appeles, dans ce 
exemple YESJ3ET REQUESTORJD et YES_CONTROL_ACCESS_ID et 
peuventetre utilises ensemble ou separement. La declaration d'une applicat.on 
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utilisant le controle de Infrastructure de communications se fait comme suit: 

mngr_name:path:(parameters):(flags):dependences:priority:0[:(ACTL_FLAGS)J 

5 ACTL_FLAGS := YES.GET_REQUESTOR.ID 

|YES_CONTROL_ACCESSJD 

|YES.CONTROL.ACCESSJD t YES.GET_REQUESTORJD 

L'indicateur YES.CONTROL.ACCESSJD signale a Infrastructure de 
10 communications que ('application se connectant avec le nom du gestionnaire 
"mngr^name 11 travaille pour d'autres applications. Le nom "mngr.name" est 
egalement utilise comme nom d'utilisateur par defaut de Tapplication. 

L'indicateur YE S_G ET_RE Q U E STO R_J D signale a I' infrastructure de 
15 communications que lorsque ^application re?oit une requete, il doit lui etre fourni 
Tidentifiant de I'utilisateur de ('infrastructure de communications demandeur de 
cette requete. 

Les exemples suivants permettent d'illustrer Putilisation de ces indicateurs: 

20 

downinthedumps;/tisv::(NO.STARTUP)::9:0:(YES_CONTROL_ACCESS_ID ( YES 
_GET_REQUESTORJD) 

eatmyhat:/bin/tfsv::(YES.STARTUP)::160:0:(YES.GET.REQUESTORJD) 

25 

drinklikeafish:/bin/tfq::(NO.STARTUP)::160:0:(YES.CONTROL.ACCESSJD) 

Dans le second cas de declaration, une application peut fournir a r infrastructure 
de communications des parametres de controle d'acces de maniere dynamique. 
30 Ces parametres sont similaires a ceux definis dans le fichier "omc". Pour 
declarer dynamiquement une application avec des parametres d'acces a 
Tinfrastructure de communications, il est necessaire d'emettre une requete 
d'action avec lesdits parametres enumeres ci-apres et contenus dans I'argument 
appele "actionlnfo": 

35 

- nom du gestionnaire, 


- nom de I'utilisateur de I'application par defaut, 
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- options (YES_CONTROL_ACCESS_ID, YES_GET_REQUESTOR_ID). 

La syntaxe precise (Asn 1) de I'argument "actionlnfo" et le format de la requete 
d'action seront explicites plus loin. 

Une application travaillant pour une autre application, peut requerir la 
connaissance de I'identifiant du demandeur de la requete recue. Par 
consequent, lorsque rinfrastructure de communications recoit une requete et que 
cette requete est a destination d'une application qui a besoin de connaitre le 
demandeur de cette requete, ('infrastructure de communications ajoute 
I'identifiant du demandeur a la requete avec I'argument de controle d'acces. 

Pour resumer, comme cela a ete exprime precedement, statiquement, une 
application demandant I'identifiant du requerant peut etre declaree en ajoutant 
au fichier "omc" I'indicateur YES_GET_REQUESTOR_ID. alors que 
dynamiquement, une requete d'action doit etre emise vers rinfrastructure de 
communications avec le parametre YES_GET_REQUESTOR_ID dans 
I'argument "actionlnfo". 

Le contrdle d'une application C travaillant pour une autre application D necessite 
un traitement particulier par rinfrastructure de communications de Implication C. 
Pour chaque requete emise par I'application C, ('infrastructure de 
communications essaie d'obtenir I'identification de I'utilisateur pour lequel ladite 
application C travaille, cette identification de I'utilisateur etant contenue dans 
I'argument de la requete de controle d'acces. Si I'argument de la requete de 
contrdle d'acces se trouve etre dans un format de controle d'acces de 
rinfrastructure de communications (syntaxe Asn 1 comme decrit dans la suite), il 
peut comporter une identification de I'utilisateur telle que le couple (ip, uid). 

Le contrfile de rinfrastructure de communications se fait de la maniere suivante. 
Si I'argument de la requete de controle d'acces ne se trouve pas dans la requete 
recue, alors il est applique un traitement par defaut. Si I'utilisateur par defaut de 
I'application C n'est pas declare dans la base de donnees alors: 

- les droits d'acces d'un "autre utilisateur", si ce dernier est declare, sont 
pris en compte par le controle de rinfrastructure de communications, 
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- si un "autre utilisateur" n'est pas declare, la requete est rejetee. 

Si par centre. I'utilisateur par defaut de I'application C est declare dans la base 
de donnees alors, les droits d'acces de cet utilisateur par defaut sont pris en 
5 compte par le controle de I' infrastructure de communications, ceci terminant le 
traitement par defaut. 

Dans le cas ou I'argument de la requete de controle d'acces est conforme a la 
syntaxe de Infrastructure de communications (par exemple syntaxe Asn 1), 

10 alors, dans I'hypothese ou le parametre de controle d'acces contient 
('identification de I'utilisateur, par exemple le couple (ip, uid), les droits d'acces 
de cet utilisateur identifie par ce couple sont utilises par le controle de 
("infrastructure de communications tandis que si I'utilisateur n'est pas declare, la 
requete est rejetee. Par contre, dans I'hypothese ou le parametre de controle 

15 d'acces ne contient pas I'identification de I'utilisateur (ici le couple (ip, uid)). le 
traitement par defaut est applique. De meme, si i'argument de la requete de 
controle d'acces n'est pas conforme a la syntaxe (par exemple Asn 1) de 
I'infrastructure de communications, le traitement par defaut est applique. 

20 Lors de renvoi de la requete vers le destinataire de I'application, si cette requete 
est acceptee, I'infrastructure de communications definit, avec le traitement de 
"routage", vers quelle application cette requete va etre envoyee et suivant le 
destinataire, I'argument de la requete de controle d'acces va etre ou ne pas etre 
modifie de la facon suivante: 

25 

- si le destinataire a besoin de r identification du demandeur de la requete 
et dans I'hypothese ou I'argument de la requete de controle d'acces est 
conforme a la syntaxe de ['infrastructure de communications (par exemple 
syntaxe Asn 1), aucune modification n'est realisee, I'argument de la requete 

30 recue est envoye comme il a ete recu, alors que dans I'hypothese inverse, 
I'identification du demandeur de la requete contenue dans le controle d'acces est 
ajoutee, 

- si le destinataire n'a pas besoin de I'identification du demandeur de la 
35 requete et dans I'hypothese ou I'argument de la requete de controle d'acces est 

conforme a la syntaxe de I'infrastructure de communications (par exemple 
syntaxe Asn 1), I'identification du demandeur de la requete contenue dans le 
controle d'acces est supprimee. alors que dans I'hypothese inverse, aucune 
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modification rTest realisee, Targument de la requete regue est envoye comme il a 
ete regu. 

Differents "echantillons" d'analyses peuvent etre obtenus avec I'analyse de 
Tinfrastructure de communications. Ainsi, lorsque le controle de Infrastructure 
de communications est correctement initialise, le message suivant apparait: 

* 

- cdsp_cdsp : [15] init. 

Lorsqu'une application se connects, les messages suivants peuvent apparaitre, 
le premier signifiant que I'acces est refuse et le second que I'utilisateur n'existe 
pas dans la table d'utilisateurs: 

- cdsp_cdsp : [4] open !! access control : REFUSED [RC=-1804] : 
uid=3028 ip=1 29.1 82.54.82, 

- cdsp_cdsp : [22] message !! [RC=-1803]. 

Lorsqu'une application emet une requete, les messages suivants peuvent 
apparaitre: 

- cdsp_cdsp : [19] invoke » [NORMAL user] control on uid=3028 : 
ip=129.182.54.82: pourun utilisateur "normal", 

- cdsp_cdsp : [19] invoke => access control -> request ACCEPTED 
[capacity=1] [instance=0]: pour signifier que la requete est acceptee, 

- cdsp_cdsp : [14] invoke => [PRMLEDGED user] request accepted: 
pour signifier que la requete est acceptee pour un utilisateur "privilegie", 

- cdsp_cdsp : [19] invoke => access control Argument is absent: pour 
signifier que I'argument de contrdle d'acces est absent. 

Suivent a present quelques exemples de capacites qui peuvent etre donnees par 
un administrateur de I'environnement de gestion distribute a un utilisateur de 
I' infrastructure de communications: 

- acces a partir de n'importe quelle operation, par exemple de type CMIS, 
a tous les objets d'une base d' informations de gestion (MIB) de I'environnement 
de gestion distribuee, 
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- acces en lecture, seulement pour une operation de type Get, a tous les 
objets d'une base d' informations de gestion (MIB) de I'environnement de gestion 
distribute, 

5 - acces a des objets d'une famille de classes: tous les objets d'une classe 

d'objets geres commencant par un identifiant d'objet precis, par exemple: 
{1.3.12.2.1009.*}, 

- acces a toutes les instances d'objets d'une classe d'objets geres, 

10 

- acces a une classe d'objets geres, mais pour des instances d'objets 
particulieres (domaines), 

- acces a une instance d'objets d'une classe d'objets geres pour des 
15 operations de type Get ou Action seulement, . • . 

- acces au moyen d'operations de type CM IS non scopees sur des objets 
geres , I'utilisateur de I' infrastructure de communications n'ayant acces qu'aux 
objets de base, 

20 

- acces au moyen d'operations de type CMIS scopees sur des objets 
geres , I'utilisateur de I' infrastructure de communications ayant acces a un sous- 
arbre sous un objet. 

25 Pour une meilleure apprehension de la mise en oeuvre de I'invention, a cet 
endroit et dans la suite, un exemple precis de syntaxe, la syntaxe Asn 1 , ainsi 
que le format d'une requete d'action sont explicites. Dans la suite aussi, 
I'abreviation "ism" correspond a I'appellation de I'environnement de gestion 
distribute. 

30 

L'argument du controle d'acces a la base d'informations de gestion via 
Tinfrastructure de communications peut contenir le couple (ip, uid) pour identifier 
le demandeur de la requete qui dans cet exemple est une requete de type CMIS. 
II peut egalement contenir le controle d'acces de I'utilisateur. 

35 

Ainsi et dans ce cas, l'argument du controle d'acces a la base d'informations de 
gestion via Tinfrastructure de communications dans la requete (CMIS) est 
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conforme a la syntaxe Asn 1 suivante: 
FmkAccesControl ::= EXTERNAL 

Plus precisement, les champs et les valeurs Asn 1 pour le controle d'acces i 
^infrastructure de communications sont les suivants: 

FmkAccesControl' ::= [UNIVERSAL 8] IMPLICIT SEQUENCE { 

fmkAccesCbntrolld OBJECT IDENTIFIER, - {1 3 12 2 1009 3 122 1} 
fmkAccesControlValue [0] EXPLICIT FmkAccesControlValue 

} 

II peut etre ici note que I'identifiant d'objet {1 3 12 2 1009 3 122 1} indique que la 
valeur "fmkAccesControlValue" doit etre dans le format de Infrastructure de 
communications. 

FmkAccesControlValue ::= SEQUENCE { 

ismSecurityToken InitialContextToken, - <= for framework 
userAccesControl EXTERNAL OPTIONAL - <= user access control 

} 

avec, 

InitialContextToken ::= [APPLICATION 0 ] IMPLICIT SEQUENCE { 
securityMechanism OBJECT IDENTIFIER, 
securityParameters ANY DEFINED BY securityMechanism 

} 

Si le mecanisme de securite "securityMechanism" = {1 3 12 2 1009 3 122 2}, 
alors le champ parametres de securite "securityParameters" suit la syntaxe 
suivante: 

Fmkldentification ::= SEQUENCE { 
uid INTEGER, 

ipAddress [APPLICATION 0 ] IMPLICIT OCTET STRING 

} 
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Si le mecanisme de securite "securityMechanism" = {1 3 12 2 1009 3 122 58}, 
alors le champ parametres de securite "securityParameters" suit la syntaxe 
suivante: 

5 FmkNoldentification ::= INTEGER 

La declaration d'une application travaillant de maniere dynamique pour une 
autre application est produite en emettant une requete d'action de type CMIS. 
Pour cette declaration, les principaux parametres sont contenus dans I'argument 
10 "Action Info" et la syntaxe Asn 1 est la suivante: 

AsncActlActionlnfo ::= SEQUENCE { 
managerName PrintableString, 
defaultName PrintableString, 
15 flags ENUMERATED {control (1 ), get (2), both (3)} . 

} 

Le parametre "ManagerName" correspond au nom de Tapplication travaillant 
pour une autre application, tandis que le parametre "DefaultName" correspond 
20 au nom de Tutilisateur par defaut de Implication travaillant pour I'autre 
application. Les parametres "flags" correspondent aux differents indicateurs 
suivants: 

- control (1) : indique que I'application dont le nom est contenu dans le 
25 champ "ManagerName" travaille pour d'autres applications, 

- get (2) : indique que Tapplication dont le nom est contenu dans le champ 
"ManagerName" requiert I' identification du demandeur de chaque requete de 
type CMIS re$ue, 

30 

- both(3): indique que Tapplication dont le nom est contenu dans le champ 
"ManagerName" travaille pour d'autres applications et, de plus, requiert 
('identification du demandeur de chaque requete de type CMIS regue. 

35 En outre, I'argument de type d'action est {1.3.12.2.1009.3.83.5.61.16.4}, tandis 
que rargument de la classe d'objets d'action est {1.3.12.2.1009.3.83.5.61.16}. 
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Lorsqu'une requete est rejetee, un message d'echec ("event violation") relatif a 
"I'^venement" est gen6re par Infrastructure de communications pour indiquer 
l'op6ration de type CMIS concernee dans la requete rejetee, la raison pour 
laquelle la requSte est rejetee ainsi que Identification du demandeur de ladite 
5 requete. Ces informations sont contenues dans Pargument "Eventlnfoargument" 
et sont conformes a la syntaxe Asn 1 suivante avec ces differentes valeurs: 

EventViolationlnfo ::= SEQUENCE { 
operation CmiseOperation, 
10 reason INTEGER, 

requestor ActlUserld, 

ManagerName PrintableString OPTIONAL 

} 

15 L* operation de type CMIS concernee est referencee par Tune de celles ci- 
dessous enumerees: 

CmiseOperation ::= ENUMERATED { 
get (3), 
set (4), 
action (6) t 
create (8), 
delete (9) 

} 

Les raisons pour lesquelles la requete est rejetee sont ci-dessous identifies: 

FWK_VIOLATION_NORMALUSER_REJ_REASON (1): lorsque le droit 
d'acces a I'objet concerne n*est pas autorise a Tutilisateur normal defmi par le 
30 couple (ip, uid). 

FWK_VIOLATION_NORMALUSER_UNKNOWNCTX_REASON (2): lorsque 
I'utilisateur normal defini, par exemple, par le couple (ip, uid) n'est pas defini 
dans la table d'utilisateurs. 

35 

FWK_VIOLATION_NORMALUSER_BADSTATE (3): lorsque les tables 
internes de ('infrastructure de communications ne sont pas initialisees. 


20 


25 
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FWK_VIOLATION.NORMALUSER_NOUSER.TABLE (4): lorsque la table 
d'utilisateurs de r infrastructure de communications n'est pas initialisee. 

FWK_VIOLATION_NORMALUSER_NODOMAIN_TABLE (5): lorsque la table 
des domaines de ('infrastructure de communications n'est pas initialisee. 

FWK_VIOU\TION_WORKINGFORUSER_REJ_REASON (13): lorsque la 
requete est emise par une application travaillant pour une autre application et 
qu'aucun droit d'acces n'est associe a la requete. 

FWK_VIOLATION_WORKINGFORUSER_UNKNOWNCTX_REASON (14): 
lorsque I'utilisateur, defini, par exemple, par le couple (ip f uid), pour lequel 
travaille I'application n'est pas defini dans la table d'utilisateurs. 

FWK_VIOLATION_WORKINGFORUSER_NODEFAULT_REASON (15): 
lorsque le nom par defaut de I'utilisateur de I'application n'existe pas dans la 
table d'utilisateurs. 

FWK_VIOLATION_NOCTX_ ANYMORE (16): lorsque I'utilisateur n'est plus 
declare dans la table d'utilisateurs a la suite de mises a jour dynamiques de 
ladite table d'utilisateurs 

De meme le dernandeur de la requete rejetee est ainsi identifie: 

ActlUserld ::= CHOICE { 

uidIP Fmkldentification, 
defaultAppliUser PrintableString 

} 

,» 

Fmkldentification ::= SEQUENCE { 
uid INTEGER, 

ipAddress [APPLICATION 0 ] IMPLICIT OCTET STRING 

} 

Enfin, si le dernandeur de la requete rejetee est un gestionnaire, le champ 
"MananagerName" represente le nom de ce gestionnaire. 
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De plus, I'argument de type "d'evenement" est {1.3.12.2.1009.3.122.1971}. 
L'argument de la classe d'objets et I'argument de I'instance d'objets represented 
I'objet de la base d'informations de gestion MIB auquel s'appliquait la requete de 
type CMIS rejetee. Dans le cas d'une requete "create" du type CMIS, I'instance 
5 ne pouvant exister, une instance fictive remplace I'instance d'objets. Egalement, 
I'argument "moment de I'evenement" represente le moment ou I'echec a ete 
constate. . 

i 

r 

La description suivante permet de preciser premierement les possibilites offertes 
10 (capacites) aux utilisateurs par ('infrastructure de communications et en second 
lieu les domaines (instances d'objets). 

II est ci-dessous propose une description des utilisateurs de ('infrastructure de 
communications et des possibilites qui leur sont offertes suivie d'un exemple 
15 concret: 

<u_file> :;= <u_tab>{"\n"<u_tab>}* 
<u_tab> ::= <u_tabJieader_entry>{'VV'<u_tab_entry>}* 
<u_tab_header_entry> ::= H ! H <uid>""<ip> | <name> 
20 <uid> ::= integer 

<ip> ipjnteger1 ,# . ,, ip_integer2 ,, ."ipjnteger3". ,, ip_integer4 
avec 

' • 1 <= ip_integer1 <= 255 

0 <= ip_integer2 <= 255 
25 0 <= ip_integer3 <= 255 

1 <= ip_integer4 <= 255 

<name> ::= M !LEN= M integer/'NAME="string 
<u_tab_entry> ::= <oc_set> ,, :"<operation>": ,, <domainjist> 
<oc_set> ::= "**' | <subtree_oids> | <only_one_oid> 
30 <subtree_oids> ::= <oid>'\*" 

<only_one_oid> ::= <oid> 

<operation> ::= "2"| "3"| "4 M | M 5 M | "6"| "7"| "8 H | M 9 H | M 10 M 
ou 

"2" correspond a I'operation "get" 
35 "3" correspond a Toperation "scoped get" 

"4" correspond a I'operation "action" 
"5" correspond a I'operation "scoped action" 
"6" correspond & I'operation "set" 
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"7" correspond a I'operation "scoped set" 

"8" correspond a I'operation "create" 

"9" correspond a I'operation "delete" 

"10" correspond a I'operation "scoped delete" 

5 

Exemple de capacites d'utilisateurs: 


# file: users 
!LEN=4,NAME=toto 
10 1.2.3.8:5:* 

13028,129.182.54.82 
*:6:* 

1.2.15.*:6:* 
13021,129.182.54.82 
15 1.2.88.4.8:3:domain1,domain2 
13023,129.182.54.82 
1 .88.4.8:3:domain1 ,domain2 
!LEN=1,NAME=t 
*:5:* 


20 


Cet exemple concret peut ainsi etre commente: 


1. Un utilisateur peut etre defini soit par un nom (!LEN=4,NAME=toto), soit 
par un couple constitue d'un identifiant uid et d'une adresse ip 

25 (13028,129.182.54.82). 

2. II est rappele que les operations de type CMIS (get scoped delete) 

sont ordonnees dans le sens croissant. De cette maniere, si un utilisateur est 
autorise a effectuer une operation "set" (6), il peut egalement effectuer les 

30 operations de niveau inferieur, get (2), scoped get'(3)j action (4), scoped action 
(5). 

3. Ensuite. associees a I'identite de I'utilisateur suivent les capacites de 
cet utilisateur. 

35 

4. La capacite "1.2.3.8:5:"*' signifie que le detenteur de cette capacite peut 
effectuer des operations du niveau get (2) jusqu'au niveau scoped action (5) sur 
toutes les instances d'objets existants et a venir (domaine* correspondent done 
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au domaine de toutes les instances possibles d'objets existants et a venir) ayant 
I'identifiant de classe d'objets 1.2.3.8. 

5. La capacite "1.2.88.4.8:3:domain1,domain2" signifie que le detenteur 
de cette capacite peut effectuer des operations du niveau get (2) jusqu'au niveau 
scoped get (3) sur toutes les instances definies dans les domaines 
(domain1,domain2) ayant I'identifiant de classe d'objets 1.2.88.4.8. 

6. La capacite 1.2.15. *:6:* signifie que le detenteur de cette capacite peut 
effectuer des operations du niveau get (2) jusqu'au niveau set (6) sur toutes les 
instances d'objets existants et a venir (domaine *) ayant comme classe d'objets 
existantes et a venir (classe* qui prend par convention toutes les valeurs 
possibles de classes) un identifiant de classe d'objets commencant par 1.2.15. 

II est a present propose une description des domaines (instances d'objets) de 
I'infrastructure de communications suivie d'un exemple concret. 

<r_d_file> ::= <r_d_tab_entry>{"\n"<r_d_tab_entry>}* 

< r _d_tab_entry> ::= <instance_length>":"<instance>":"<domainJist> 

<instance> ::= <rdn>{'7"<rdn>}* 

<instance_length> ::= integer{integer}* 

<rdn> ::= <oid>"="<value> 

<oid> ::= integer{"."integer}* 

<value> ::= string 

<domain_list> ::= <domain>{","<domain>}* 
<domain> ::= <universe_domain> || <domain_name> 
<universe_domain> ::= 
<domain_name> ::= <domain_string> 
<domain_string> ::= all printable characters 
EXCEPT 7 

i.i 

T 

•#■ 

i i 
i i 

['\n'] 


10 


15 
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Exemple de domaines: 
# domains file 

31:1.3.12.2.1009.3.46.1.1.1 =130169:ff,domain1,domain2,capAIIDomiii 
12:1.4.6=020101:* 

37:1 .2.4.3.3.3.3.3.3=0201 05/1 .2.3=0201 01 :do1 ,do2 

1 1 5: 1 .2.3. 1 971 . 1 0. 5= 1 304686f61 6e/1 .2.3. 1 981 . 1 0.5=040431 323334/1 .2.3. 1 995. 

17.5=020205d4/1 .2.3.1 995. 17.5=06062a038f4b1 105:dom1 

39: 1 .3.1 2.2. 1 009.3.55. 1.1.1.1=1 30469782d69:cap2d, DomCapNovell 


Cet exemple peut etre commente ainsi: 

1. Dans le fichier "domaines", chaque instance est representee par une 
longueur et une chaine de caracteres. 

2. Pour chaque instance, une liste de domaines est associee, I'instance 
appartenant aux domaines de la liste. 

3. (.'instance "1.2.4.3.3.3.3.3.3=020105/1.2.3=020101" a pour longueur 37 
20 et appartient aux domaines 1 et 2 (do1 et do2). 

Pour conclure, le present procede de controle d'acces a la base d' informations 
de gestion via Infrastructure de communications liant des applications permet, a 
partir de finfrastructure de communications, d'avantageusement controler tout 

25 objet, puisqu'un controle d'acces a la base d'informations de gestion d'un 
utilisateur d'une application, directement ou indirectement connectee a ladite 
infrastructure de communications, est effectue au niveau exact d'un objet ou d'un 
ensemble d'objets precisement determines et appartenant a une quelconque 
classe repertoriee dans la base de donnees, mas egalement au niveau des 

30 operations desirees realisees, selon la requete emise, sur des instances d'un ou 
plusieurs desdits objets determines. Ceci est autorise du fait que sont 
judicieusement exploitees I'ensemble des caracteristiques de finesse et de 
precision presentees par un protocole administratif, de preference le protocole 
CMIP avec ses fonctions particulieres. Avec ce procede et avec le protocole 

35 CMIS/CMIP qui permet d'aider efficacement a ^unification d'un ensemble d'objets 
a traiter, un quelconque ensemble d'objets heterogenes peut etre aisement 
administre alors qu'avec les precedes de I'art anterieur, chaque protocole 
necessitait une application particuliere. Egalement de maniere fondamentale, 
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alors que Tapplication ou I'utilisateur d'une application directement connectee a 
I'infrastructure de communications est identifie au moyen de son adresse et de 
son identifiant ou au moyen d'une chaine de caracteres, autorisant, lorsque 
rutilisateur est reconnu, la connection et I'acces aux droits definis dans la base 

5 de donnees, dans le cas bu une premiere application est indirectement 
connectee a I'infrastructure de communications par I'intermediaire d'une seconde 
application directement connectee a I'infrastructure de communications sous un 
nom particulier, les requetes et les reponses aux requetes transitant par la 
seconde application, si la seconde application travaillant alors pour la premiere 

10 application donne avec remission de la requete I'identite de I'utilisateur de la 
premiere application, I'infrastructure de communications controle la requete 
comme si cette premiere application avait envoye directement ladite requete, 
alors que si la seconde application ne precise pas, dans la requete. I'identite de 
la premiere application, I'infrastructure de communications realise le controle en 

15 utilisant les droits par defaut d'un utilisateur de la seconde application si cet 
utilisateur est defini tandis que si ce dernier n'est pas defini, I'infrastructure de 
communications realise ce controle en utilisant les droits d'un utilisateur 
particulier appele "autre utilisateur" si ce dernier est defini dans la base de 
donnees. Selon une autre caracteristique avantageuse de I'invention, toutes les 

20 definitions des utilisateurs de ('infrastructure de communications ainsi que leurs 
droits relatifs sont stockes dans une base de donnees. de maniere a ce que, 
, lorsqu'une application demande a etre connectee a I'infrastructure de 
communications, cette derniere puisse verifier I'existence de I'identite de 
I'utilisateur dans ladite base de donnees pour accepter ou interdire, si I'identite 

25 n'est pas trouvee, la connexion. 
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Revendications: 


1. Procede de controle d'acces a la base d'informations de gestion via 
5 I'infrastructure de communications liant des applications, d'une application ou 

d'un utilisateur d'une application donnee emettant une requete vers un ou 
plusieurs objets specifies dans un environnement de gestion distribute, 
caracterise en ce que Tapplication ou I'utilisateur de I'application, connectee 
directement ou indirectement a I'infrastructure de communications, se voit 

10 contrdler ses droits d'acces definis dans un element d'une liste dite de capacites 
stockee dans une base de donnees, une capacite etant constitute d'une classe 
ou d'un ensemble de classes d'objets contenant le ou les objets specifies et d'un 
ensemble d'operations autorisees et ordonnees, I'operation correspondant a la 
requete emise et, si elle est autorisee, etant a effectuer sur des instances du ou 

15 des objets specifies de ladite classe d'objets, les objets traites etant de nature 
heterogene. 

2. Procede de controle d'acces a la base d'informations de gestion via 
I'infrastructure de communications selbn la revendication 1, caracterise en ce 

20 que I'application ou I'utilisateur d'une application directement connectee a 
I'infrastructure de communications est identifie soit au moyen de son adresse et 
de son identifiant, soit au rrioyen de son nom repertorie par un service de 
nommage, autorisant, lorsque I'application ou I'utilisateur de I'application est 
reconnu, la connection et I'acces aux droits definis dans la base de donnees. 

25 

3 Procede de contrdle d'acces a la base d'informations de gestion via 
rinfrastructure de communications selon la revendication 1, caracterise en ce 
que, dans le cas ou une premiere application est indirectement connectee a 
I'infrastructure de communications par I'intermediaire d'une seconde application 

30 directement connectee a rinfrastructure de communications sous un nom 
particulier, les requetes et les reponses aux requetes transitant par la seconde 
application, si la seconde application travaillant alors pour la premiere 
application donne avec remission de la requete I'identite de I'utilisateur de la 
premiere application, I'infrastructure de communications controle la requete 

35 comme si cette premiere application avait envoye directement ladite requete, 
alors que si la seconde application ne precise pas, dans la requete, I'identite de 
la premiere application, I'infrastructure de communications realise le contrdle en 
utilisant les droits par defaut d'un utilisateur de la seconde application si cet 
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utilisateur est defini tandis que si ce dernier n'est pas defini, Pinfrastructure de 
communications realise ce contrdle en utilisant les droits d'un utilisateur 
particulier appel6 "autre utilisateur" si ce dernier est dgfini dans la base de 
donnees. 

5 

4. Procede de contrdle d'acces a la base d' informations de gestion via 
T infrastructure de communications selon Tune des revendications 1 & 3, 
caracterisd en ce quQ, chaque requete §mise est testee relativement aux droits 
d'acces d'un utilisateur d'une application ou d'une application, ce test consistant 

10 a verifier le type de la requete et son niveau dans une suite ordonnee de 
requetes, la classe d'objets requise qui peut £tre etre une classe autorisee ou 
une classe appartenant a I'ensemble des classes autorisees defini dans une 
capacity et I'appartenance de Pinstance d'objets requise a un ensemble 
^instances d'objets autorise appel6 domaine. 

15 

5. Procede de controle d'acces d la base d' informations de gestion via 
I' infrastructure de communications selon Tune des revendications precedentes, 
caracterise en ce que, chaque requite emise est testee relativement aux droits 
d'acces des utilisateurs, ces droits 6tant d6finis de fagon non enum§rative sur 

20 des classes non encore connues et des instances non encore decouvertes de 
telle maniere que: 

- les classes d'objets testees ou un ensemble de classes d'objets test6es 
aient un radical commun et notamment la classe* (classe etoile) designant toutes 

25 les classes existantes et a venir, 

- un domaine d'instances d'objets soit d6fini comme un ensemble 
cf instances d'objets existants et a venir appel6 domaine* (domaine etoile), 

30 - par la definition d'une requSte scopee sur un domaine, un utilisateur 

d'une application ait acces £ toutes les instances d'objets appartenant a ce 
domaine mais aussi aux instances tfobjets qui sont hierarchiquement inferieures 
relativement auxdites instances d'objets appartenant a ce domaine dans la base 
d'informations de gestion. 

35 



INTERNATIONAL SEARCH REPORT 


A. <XASSin<^TION OF SUBJECT MATreR 

IPC 6 606F12/14 GG6F1/00 


Acort.n. u» tour**™* Paum Q^fic^ - HPO or to bo«h na.ona. dasTicaion and IPC , 

B. FIELDS SEARC HED 

Mrtumum docunMUEon searched (cla^ caoon sy~m fcUowed by da»fica B on symbo.,) 

IPC 6 G06F H04L 


onal Application No 

>Ci/FR 97/90251 


Electronic data, base consul led during the 


mVernaoonal search (name of data base and, where practical, search term used) 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category " 


A 
Y 


Citation of document, «* .mficaoon, wh«r« appropnatt. of the relevant passage, 

US 5 305 456 A (BO I TANA GEORGE A) 19 April 
1994 

see the whole document 

US 4 956 769 A (SMITH ROBERT D) 11 
September 1990 
see the whole document 

EP 0 658 848 A (SUM MICROSYSTEMS IMC) 21 
June 1995 

see abstract . 
see column 4, line 5 - column 5, line 10 


Relevant to claim No. 


2 
1 

1.3 


| py| Further document* are listed in die continuation of box C. 

* Spcoal categories of a ted documents : 

*A' document defining the general state of the art which is not 

considered to be of particular relevance 
•E- earlier document but published on or after the international 

Gling date 

- L - document which may throw doubts on pnonly daim(s)or 
\Sruc^*Udu> establish the publicans date of another 
o taboo or other special reason (as specified) 

•O* document referring to an oral disclosure, use, exhibition or 
other means 

•P- document published prior to the international King date but 
later than the priority date claimed 

Date of the actual completion of the international search 

30 May 1997 

Name and mailing address of the ISA 

European Patent Office, P.B. 5*1 * Patentlaan 2 

NX - 22«0 HV Riiswijk 

Tel. ( + 31-70) 340- 204a Tjl 31 651 epo nl. 
Faic (+ 31-70) 340-3016 

Form PCT.1SA.-aiO thwt) (July 


El 


Patent family members are listed in annex. 


-T later document published after tt* ^^ on ^J^J^ JIL 
or pnonty date and not in conflict with the apphcauon but 
ated to understand the principle or theory underlying the 
invention 

*X* dctcurncnt of particular relevance; the claimed invenuoo 
aZ£*t* coSnSred novel or cannot be «r«dered to 
involve an inventive step when the document is taken alone 

•V document of particular relevance; the claimed invention 
cannotbe conS dered to mvc4v« an in vennve step whence 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person stalled 
in the art. 

*£* document member of the same patent family 
Date of mailing of the internanonal search report 


05.06.97 


Authorized officer 


Powell, D 


page 1 of 2 


IN 


NATIONAL SEARCH REPORT 


| PC 


-*n*i Application No 

i/FR 97/00251 


C^Cootuuiaoon) DOCUMENTS CONSIDERED TO BE RELEVANT 


C Ate gory ' 


Quo on of document, with indication, where appropriate, of Che relevant passages 


Relevant to daun No. 


IBM TECHNICAL DISCLOSURE BULLETIN, 
vol. 34, no. 7B, 1 December 1991, 
pages 114-117, XP000282519 "EXTENSIBLE 
ACCESS CONTROL LIST MECHANISM" 
see the whole document 

EP 0 599 706 A (BULL SA) 1 June 1994 


Form PCT/ISA/Ilt (continuabo* of ncoad (July Itf3) 

page 2 of 2 


INTERNATIONAL SEARCH REPORT 

^^HnaUon on patent family members 


^C'l 


->iul Application No 

/FR 97/00251 


Patent document 

1 Publication 1 
date 1 
J ■ 

Patent family 
member(s) 

date 

US 5305456 A 

19-04-94 

NONE 


lie* AftCCt CO A 

US 49bo/b9 A 

11-09-90 

NONE 


EP 0658848 A 

21-06-95 

US 5481715 A 
JP 7234846 A 

02-01-96 
05-09-95 


EP 0599706 A 


01-06-94 


FR 
BR 
CA 
HU 
JP 
JP 


2698461 
9304748 
2102538 
65297 
2504694 B 
6214901 A 


A 
A 
A 
A 


27-05-94 
31-05-94 
24-05-94 
02-05-94 
05-06-96 
05-08-94 


RAPPORT DE^CHERCHE INTERNATIONALE DcTr , e (rUOTAQonAle No 

™ PC./FR 97/00251 


A. CLASS EM E NT DE L*OBJET DE LA OEMANDE 

CIB 6 G06F12/14 GO6F1/O0 


Scion la classification mtcmaoonale des brevets (CIB) ou a la foil sdon la classification nahonale et U CIB 


8. DOMAINES SUR LES QUELS LA RECHERCHE A PORTE 


Documentation miramalc consul tee (lysteme de classification suivi des symbolcs de cUscmmt) 

CIB 6 G06F H04L 


Documentation consultee autre que la docwncnUQon minimale dam la mesure ou ccs documenit rei event des domaincs sur Icsquels a port* la recherche 


Bmc ^ donnecs electitMuque consult* au cours de la recherche Internationale <nom de la base de donnees. ci si cela est realisable, termes de recherche 
utilises) 


C. DOCUMENTS CONSIDERES COMME PERTINENTS 


Categone ' 


Identification des documents cites, avec, le cas echeant. Indication des passages pertinems 


no. des re vendt canon* visees 


US 5 305 456 A (BO I TANA GEORGE A) 19 Avril 
1994 

voir le document en entier 


US 4 956 769 A (SMITH ROBERT D) 11 

Septembre 1990 

voir le document en entier 

EP 0 658 848 A (SUN MICROSYSTEMS INC) 21 
Juin 1995 
voir abrege 

voir colonne 4, ligne 5 - colonne 5, ligne 
10 


2 
1 

1.3 


| x| Voir la suite du cadre C pour la 


fin de la liste des document! 


Les documents de families de brevets som indiquea en annexe 


* Categories speaales de documents atex 

•A* document defintssani letat general de la technique, non 

consider* comme pamcuhercment pertinent 
*E" document anteneur. mais pubtie a la date de depot international 

ou apres cette date 
X" document pouvant jeter un doute sur une revendication de 

pnoritc ou ate pour determiner la date de publication d une 

attire citation ou pour une raisoo speoalc (telle qu'indiquee) 
•O* document sc referant a une divulgation orale, a un usage, a 

une exposition ou to us autres rnoyera 
"P* document public avant la date de depot international, mais 

posxericurcraent a la date de pnontt rcvcndiauec 


T* document ulterieur public apres la date de depot international ou la 
date de pnontt et n'appartencnant pas a I'etat de la 
technique pc/tincnt, mais cite pour comprendre le principe 
ou la theorie consu taint la base de 1* invention 

*X* document parti cuherrmcnt pertinent 1'invention revendiquee ne pcut 
eire consider* e comme nouvejlc ou comme impb quant une acttvitt 
inventive par rapport au document conridere isolement 

*Y" document paracufaercment perunenq rinvention revendiquee 

ne pcut etre coctsderee comme imph quant une acttvitt inventive 
torsquc le document est assoac a un ou pluneurs autres 
documents de meme nature, cette combmaison etant cvidente 
pour unc pcrsonne du metier 

*A" document qui (ait parte de la meme f ami lie de brevets 


Date a laqucllc la recherche Internationale a ttt efTectivcmcnt achevee 

30 Mai 1997 


Date d' expedition du present rapport de recherche Internationale 

0 5. 06.97 


Nom et 


le de r administration chargce de la recherche Internationale 
OCIke Europecn des Brevets, P.B. 581 1 Patenuaan 2 
NL - 22S0 HV Rijmjk 
TeL t+ 31-70) 340-2040, Tx. 31 651 epo nl. 
Fax (<r 31-70) 340-3016 


Fonchormairc autonsc 


Powell , D 


Formulate* PCT/1SA/318 (dctuuam fmuMm) (juiBM 1912) 


page 1 de 2 


RAPPORT DE RECKERCHE INTERNATIONALE 


• tntcnuoorule No 

pTi/FR 97/00251 



C.(iuit£) DOCUMENTS CONSIOERES COMME PERTINENTS 


Citpne * I Idenoficaaon dcs documents cites, avee. le cas echeant. limUcanon da passages peraneMS 


IBM TECHNICAL DISCLOSURE BULLETIN, 
vol. 34, no. 7B, 1 Decembre 1991, 
pages 114-117, XP000282519 "EXTENSIBLE 
ACCESS CONTROL LIST MECHANISM" 
voir le document en entier 

EP 0 599 706 A (BULL SA) 1 Juin 1994 


Fonmmin PCT/lSA/llO <»*• «• la 


fe«Ula) (|uiU.t IStl) 


page 2 de 2 


RAPPORT DE 

fUmeigncmcntt relaofs au. 


HERCHE INTERNATIONALE 

mbra dc families <U brcvtu 


• Internationale No 

PCVFR 97/00251 


Document brevet cite 
au rapport de recherche 


Date de 
publication 


Membrefs) de la 
famille de brevei(i) 


Date de 
publication 


US 5305456 A 
US 4956769 A 


19-04-94 
11-09-90 


AUCUN 
AUCUN 


EP 

0658848 

A 

21-06-95 

US 
JP 

5481715 
7234846 

A 
A 

02-01-96 
05-09-95 

EP 

0599706 

A 

01-06-94 

FR 

2698461 

A 

27-05-94 



BR 

9304748 

A 

31-05-94 





CA 

2102538 

A 

24-05-94 





HU 

65297 

A 

02-05-94 





JP 

2504694 

6 

05-06-96 





JP 

6214901 

A 

05-08-94 


FormuUim PCT/UA/310 « 


tmmiOm 4m ktvw) <jutfl*t 1993) 


This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 


Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 


□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 


BEST AVAILABLE IMAGES 



iLURRED OR ILLEGIBLE TEXT OR DRAWING 


This Page Blank (uspto) 


